1. Field of the Invention
This invention pertains in general to computer software update deployment, and more specifically to techniques for controlled release of software updates to random subsets of seed users over time.
2. Description of the Related Art
Deploying a software update to a large number of users at a time can pose numerous problems since such updates sometimes introduce software bugs or cause other problems when released to the public, even after the updates have undergone substantial testing to avoid such problems. Regardless of how thoroughly the software update is tested before release to the public, when targeting a large number of disparate machines to receive a software update, it is difficult to guarantee that none of the machines will have a problem with the new software. Thus, when sincere attempts at providing bug-free software updates to the public fails, it is helpful to have some sort of mechanism to mitigate the effects of the problems as quickly as possible.
Software companies have attempted to deal with this problem by limiting the initial release of a new software update to only a subset of all possible users. If a software update is released to only 10,000 machines in a first round of release rather than to the entire pool of millions of users, it is much easier to deal with any problems or bugs introduced by the software that may not have been discovered during prior testing of the software. The users who are affected by the problem are much fewer and more manageable in this type of limited initial release.
There are a number of different ways in which this type of limited software update deployment has been performed. One method involves limiting the initial release only to users in a particular target country or some other defined subset of users. For example, all users in Denmark for a particular software application that is being updated will receive the update first and can report any problems with the software before it is released to the general public. However, this manual release method has caused problems in the past when, for example, a particular bug only manifested itself in the target country and nowhere else. Thus, in those instances, the testing of the product by the seed users in the target country was not representative of the entire population of users of the software application to whom the update would ultimately be deployed.
Another method for limiting update release includes the timed posting and removal of updates. For example, the software update can be made available to the general public at 2 a.m. for a couple of hours, and then the update can be removed. The goal of this method is to permit a subset of users to have a chance to download the update during this two-hour window, and those users can report problems with the software update before it is released more generally to the public. The company distributing the software can monitor for bug reports and reports of system crashes to determine whether the update is ready to be provided to a broader group of users. This manual release method, however, is still not very useful because there are no statistics tied into the update release, and there is no way to know who the seed users are or whether the coverage of the seed user base is adequate for testing the software before a much wider release.
None of the above manual methods of release provide a sufficient amount of control over the software update deployment. However, control is particularly important in situations where software updates have to be released on a very short time frame, since the patch may be needed to resolve a current issue that users are facing with the software. If the software update has to be released within a week, there is very little time to run an actual beta test cycle for the update. For example, the posting and removal of software at 2 a.m. may have to be repeated numerous times over a few days to get enough downloads to form a significant enough seed user base. However, for a critical software update for which time is of the essence, there may not be time to develop a representative base since there may not be time for numerous postings and removals. Even if this critical software update is thoroughly tested before its initial release, there is still a possibility that a problem could arise upon release to the public. It would be best to contain any potential problems within a limited subset of users, but the rapid deployment and time critical nature of software updates can exacerbate this problem.
Therefore, there is a need in the art for a method that allows a more rapid and more uniform mechanism of systematically sending out software updates to a defined and random proportion of seed users before the mass distribution of the update, allowing software updates to be controlled to a much more granular level. Additionally, what is needed is the ability to specify software update distributions so that, for given periods of time, specified portions of the user population are automatically allowed to receive an update.